Terminals, such as smartphones or personal computers (PCs) are nowadays capable of activating and using a plurality of logic interfaces associated with one or more physical interfaces. Such terminals are said to be multi-interface (MIF) terminals. When a terminal has a plurality of interfaces capable of connecting it to different access networks (e.g.: fixed, mobile, or WLAN), it benefits from access that is said to be “hybrid”, because it combines different access network technologies.
A plurality of IP addresses can be allocated to such MIF terminals so that they can connect to different types of network such as a fixed network, a mobile network, or a wireless local area network (WLAN), where the emblematic example would be a WiFi network, and in a manner that may be simultaneous or deferred. These IP addresses may:                belong to the same family of addresses or to different families of addresses (IPv4, IPv6, or both);        have different lifetimes;        have different scopes, e.g. a private IPv4 address, a unique IPv6 address of local scope (i.e. a unique local address (ULA)), or an IPv6 address of global scope (global unicast address (GUA)); and        be allocated to the same logical network interface or to different logical network interfaces.        
Nevertheless, it should be observed that the “MIF” characteristic is volatile, since the ability to use a plurality of interfaces depends on conditions of connection to the network(s), on the location of the device, or on other factors. An MIF device may in particular make use of a plurality of interfaces that are available to it while setting up a simple connection (i.e. a connection set up along a single path with a given third party), or after setting up a simple connection. It may also be observed that a device does not know a priori whether it has the possibility of using a plurality of distinct paths for setting up a connection with a given third party. More precisely, the device acquires this information (where appropriate) only at the end of a stage during which it attempts to set up a multipath connection with the third party.
It should be recalled that a “multipath connection” is a connection set up between two devices and simultaneously following one or more paths between those two devices. Such a connection complies with a dedicated protocol, such as multipath TCP (MPTCP) which may optionally be defined as an extension of a previously defined transport protocol, such as transmission control protocol (TCP). In other words, a multipath connection is an aggregate of one or more simple connections following the same path or different paths (which may be partially or completely disjoint).
It should also be recalled that in the field of networks, the term “link aggregation” designates grouping together a plurality of links that are associated with a corresponding number of “logical” interfaces as though they were a single link associated with a single interface, in particular for the purpose of increasing data rates beyond the limits of a single link, but also for applying the same operating procedures to all of the links aggregated in this way (a concept referred to as “fate sharing”). In particular, service offers relating to a terminal having hybrid access rely on introducing functions into the network in order to make it possible to aggregate all of the network connections of a terminal (e.g.: WLAN and 3G, or: ADSL, WLAN, and 4G).
Link aggregation may optionally also ensure that other interfaces take over if a network link should fail (redundancy principle). Link aggregation applies to any type of traffic conveyed over such links, including IP traffic.
Link aggregation could also be used for sharing traffic over a plurality of links. Under such circumstances, the sharing of traffic among the links that make up an aggregate depends on various parameters; the sharing of traffic may depend for example on the type of traffic, such as transmission control protocol (TCP) or user datagram protocol (UDP), or on the traffic engineering policy, such as the required quality of service (QoS).
By way of example, FIG. 1a shows a terminal T connected to a server S via a plurality of IP networks referenced R1, . . . , Rm, and O, by implementing the multipath TCP (MPTCP) connection protocol. The various access networks R1, . . . , Rm may be of wired, wireless, or other natures; furthermore, these accesses may be multiple, i.e. the terminal T may have the capacity to connect to different access networks optionally in simultaneous manner.
Likewise, FIG. 1b shows a terminal T compatible with MPTCP or only with TCP, and located behind a piece of equipment referred to as a proxy-device R; the proxy-device R is itself connected to a server S via a plurality of IP networks written R1, . . . , Rm, and O, implementing the multipath TCP connection protocol (MPTCP).
In general manner, the term “proxy-device” is used to designate a piece of equipment located in the network and acting on behalf of one or more client-devices, such as a terminal or a gateway. This configuration enables the client-device to benefit from optimized use of available network resources, and also to set up multipath connections quickly.
It should be observed that link aggregation makes no assumptions about the configuration of the remote machine. Thus, a source machine may activate a link aggregation function without the remote machine using such a function.
Various modes of aggregation may be envisaged, including the following three modes:                backup mode: this mode consists in using secondary paths in the event of primary paths being unavailable, with this being for the purpose of improving the availability of the network and thus the robustness and the reliability of IP connections set up over the various links;        bonding mode: this mode consists in using the resources associated with some or all of the available paths, the IP streams associated with a given application possibly being shared among a plurality of paths; the decision to use all of the paths, or only some of them, may for example be conditioned by the nature of the traffic or the availability or reliability characteristics associated with each path, which characteristics may vary greatly from one path to another; all of the paths selected for this bonding mode are considered as being primary paths; and        a “comfort” mode: this mode is similar to the bonding mode, except that the streams of a given application are not shared among a plurality of paths, but are sent over a single path.        
It should be observed that these modes are not mutually exclusive, and that they are not specific to any one particular type of traffic. Thus, they may be put into place independently of the nature of the traffic that is to be conveyed along paths aggregated in one or another of the various modes.
Nevertheless, using multiple paths for setting up communications raises problems of various kinds.
It is commonly accepted that the use of load sharing mechanisms between a plurality of paths needs to ensure that those paths possess a comparable level of quality of transfer, in particular so as to avoid weakening the integrity of the data that is characteristic of a given connection and that is exchanged over those various paths (the quality of transfer may be characterized by a plurality of parameters including, in particular: latency, jitter, and/or rate of packet loss).
When a terminal benefits from hybrid access, its actual ability to make use of all of its interfaces is generally associated with the quality of each of the access networks in question, as perceived by the terminal, or by an application that is active in the terminal. This quality may be expressed in terms of available bandwidth, or of time to access a desired resource, or indeed in terms of variation in transmission delay, as specified in Document RFC 3393 of the Internet engineering task force (IETF). This quality naturally varies from one access network to another, and may present considerable disparities that could compromise setting up a multipath communication over the various access networks; the risk of a loss of integrity of the streams exchanged during the communication increases with any increase in such differences, to such an extent that the communication might become unintelligible. Furthermore, this disparity varies over time, e.g. as a function of the level of utilization of the resources of a network. The quality of the aggregated link also depends on the locations and the effectiveness of the network functions that enable of the network connections of a terminal to be aggregated.
These different quality levels can compromise setting up additional subflows in the context of a multipath connection. The magnitude of the above-mentioned risk of loss of integrity might incite the terminal to set up a simple connection only, even though that means losing the benefits of a multipath connection, such as optimizing available bandwidth resources or preserving continuity of a connection in the event of loss of attachment to a first network and re-attachment to a second network.
Such a risk is also made worse in the context of a terminal that does not have its own means enabling it to set up a multipath connection, and doing this by involving a proxy-device such as the device described briefly above. In this context, the question of disparity between the quality levels associated with using a plurality of available proxy-functions (e.g. depending on the location of the remote terminal with which the terminal seeks to set up a communication) becomes correspondingly more complex to solve when the terminal does not necessarily have the information and the intelligence required for selecting the proxy-device that presents the best guarantees of quality, e.g. depending on the nature of the traffic, of the application, or of the service associated with the communication.
Furthermore, at present, multipath protocols have not yet been adopted in generalized manner by content servers. Thus, some content servers process multiple connections as disjoint connections, and do not have a mechanism enabling them to correlate a plurality of connections in order to associate them with a single terminal, which has the unfortunate consequence of preventing any attempt at setting up a multipath connection, as shown in FIG. 2a. 
As shown in FIG. 2b, this problem of a server being incompatible with multipath connections has an impact on the effectiveness of the communications of any terminal seeking to communicate with such a server, whether the terminal is connected directly to the network or via a proxy-device.
In order to assist terminals, residential gateways (e.g. home or business gateways), set-top boxes, or other client-devices in setting up and maintaining connections via multiple paths, IP connectivity suppliers make use of devices referred to as “network connection concentrators”. A “network connection concentrator” designates any network function making it possible to aggregate connections making use of different paths that might be used by a device in order to set up a communication with a remote device.
By way of example, a network connection concentrator (the term “concentrator” on its own is used below for reasons of concision) may be a function in a residential gateway, it may cohabit with an MPTCP or with a stream control transmission protocol (SCTP) proxy-function, or with a generic routing encapsulating (GRE) tunnel termination point, or indeed it may be a termination point of IP-in-IP tunnels or of level 2 tunnels. Where appropriate, the aggregation of all the multiple paths by a concentrator may give rise to one or more virtual tunnels being set up, e.g. in order to facilitate management operations associated with setting up the communication (by isolating the traffic exchanged over the various paths that have been aggregated in this way, and by improving the process for detecting failures).
As examples, FIGS. 3a, 3b, and 3c show various types of architecture associated with network connection concentrators.
These figures show a terminal T connected to one or more IP networks R1, . . . , Rm, or O via N nodes (P1, P2, . . . , PN) having a network connection concentrator function. By way of example, such a node may be a gateway (home or business) or an IP router. In the figures, it can be seen that:                the terminal may be connected to a single network O managed by a single IP connectivity supplier that has deployed at least one network connection concentrator (FIG. 3a); or        the terminal may be connected to m networks R1, . . . , Rm, all hosting at least one network connection concentrator (FIG. 3b); or indeed        the terminal may be connected to m networks R1, . . . , Rm, some of which host a plurality of network connection concentrators (FIG. 3c).        
Advantageously, intervention by a network connection concentrator has the particular effect that a connection that is seen by a local device as being a multipath connection may be seen by a remote device as being a plurality of simple connections, as shown in FIG. 4.
However an IP connectivity supplier can equally well decide to use a network connection concentrator on the path(s) over which a communication is set up, even if the remote device is compatible with multipath connections (e.g. MPTCP). Specifically, using a concentrator serves advantageously to monitor continuously the quality of the aggregated connection, e.g. as a result of activating so-called “TCP connection acceleration” mechanisms. Furthermore, the presence of the concentrator facilitates activating the filters required for legal interception needs, since all of the traffic passes through the concentrator.
In order to optimize the resources supplied by concentrators, network operators seek to manage load sharing among concentrators deployed in their networks in order to set up and maintain multipath connections. For example, an operator may desire:                to withdraw a concentrator from a certain connection between two endpoints, but without thereby withdrawing the concentrator from one more connections having other endpoints, with this being for the purpose of reducing the load on the concentrator; or        to withdraw a concentrator from all of the connections with which it is involved, with this being for the purpose of facilitating maintenance operations on the concentrator (e.g. planned major software updating operations).        
The operator then needs to deal with several technical problems. In order to fix ideas, assume that one of the endpoints is a terminal of a subscriber to the network, while the other is a content server that can be reached via the network. The operator then needs in particular to deal with the following difficulties:                if the terminal is compatible with multipath connections but the server is not, withdrawing the concentrator from the connection will have the result that the operator will no longer be able to offer the same level of quality to the subscriber as is provided by using a concentrator, possibly to such an extent as to lose the benefit of having a multipath connection set up by means of the concentrator (e.g. improving access time to content); and        even if the terminal and the server are both compatible with multipath connections, withdrawing (possibly prematurely) the concentrator (which is in series between the endpoints) will lead to a break in the connection, which break is not desired by the terminal or by the server.        